UN-2265 [FEAT] Show the running platform version on the profile page#2034
UN-2265 [FEAT] Show the running platform version on the profile page#2034athul-rs wants to merge 4 commits into
Conversation
Bake the build VERSION into the frontend image as UNSTRACT_APPS_VERSION (same pattern as backend.Dockerfile), surface it through the runtime config injected at container start, and show it as a 'Platform Version' field on the profile page. Production CI already passes *.args.VERSION to all images via docker bake, so published images carry the real version on every deployment target; the field is hidden when no version is available (e.g. local npm start). Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Organization UI Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (2)
🚧 Files skipped from review as they are similar to previous changes (2)
Summary by CodeRabbit
WalkthroughAdds a version value from Docker Compose into runtime config, exposes it through frontend config, and shows it in the profile UI when present. ChangesPlatform version exposure
Estimated code review effort🎯 2 (Simple) | ⏱️ ~10 minutes 🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✨ Finishing Touches📝 Generate docstrings
🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
|
| Filename | Overview |
|---|---|
| docker/docker-compose.yaml | Adds UNSTRACT_APPS_VERSION=${VERSION} to the frontend service environment; correctly inherits the same VERSION variable used to tag images. |
| frontend/generate-runtime-config.sh | Adds js_escape helper and injects version into window.RUNTIME_CONFIG; correctly defaults to empty string so the UI field stays hidden when the env var is unset. |
| frontend/src/config.js | Exposes config.version with runtime-config-first, VITE_VERSION-fallback priority; correctly falsy when neither source is set. |
| frontend/src/components/profile/Profile.jsx | Conditionally renders Platform Version using existing field-group styling; only shown when config.version is truthy. |
Sequence Diagram
%%{init: {'theme': 'neutral'}}%%
sequenceDiagram
participant Compose as docker-compose / Helm
participant Script as generate-runtime-config.sh
participant Config as window.RUNTIME_CONFIG
participant JSConfig as config.js
participant UI as Profile.jsx
Compose->>Script: "UNSTRACT_APPS_VERSION=v0.144.0 (at container start)"
Script->>Script: js_escape(UNSTRACT_APPS_VERSION)
Script->>Config: write version: "v0.144.0"
Config->>JSConfig: runtimeConfig.version
JSConfig->>UI: "config.version = "v0.144.0""
UI->>UI: "{config.version && Platform Version field}"
%%{init: {'theme': 'base', 'themeVariables': {"darkMode": true, "background": "#0d1117", "primaryColor": "#21262d", "primaryTextColor": "#e6edf3", "primaryBorderColor": "#8b949e", "lineColor": "#8b949e", "textColor": "#e6edf3", "edgeLabelBackground": "#161b22", "actorBkg": "#21262d", "actorBorder": "#8b949e", "actorTextColor": "#e6edf3", "actorLineColor": "#8b949e", "signalColor": "#8b949e", "signalTextColor": "#e6edf3", "noteBkgColor": "#373320", "noteBorderColor": "#d4a72c", "noteTextColor": "#f0e6c0", "labelBoxBkgColor": "#21262d", "labelBoxBorderColor": "#8b949e", "labelTextColor": "#e6edf3", "loopTextColor": "#e6edf3", "activationBkgColor": "#30363d", "activationBorderColor": "#8b949e"}}}%%
sequenceDiagram
participant Compose as docker-compose / Helm
participant Script as generate-runtime-config.sh
participant Config as window.RUNTIME_CONFIG
participant JSConfig as config.js
participant UI as Profile.jsx
Compose->>Script: "UNSTRACT_APPS_VERSION=v0.144.0 (at container start)"
Script->>Script: js_escape(UNSTRACT_APPS_VERSION)
Script->>Config: write version: "v0.144.0"
Config->>JSConfig: runtimeConfig.version
JSConfig->>UI: "config.version = "v0.144.0""
UI->>UI: "{config.version && Platform Version field}"
Reviews (4): Last reviewed commit: "Merge remote-tracking branch 'origin/mai..." | Re-trigger Greptile
There was a problem hiding this comment.
Actionable comments posted: 1
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@frontend/generate-runtime-config.sh`:
- Line 13: The runtime-config write interpolates UNSTRACT_APPS_VERSION directly
into a JS string (version: "${UNSTRACT_APPS_VERSION:-}"), which can break the
resulting runtime-config.js if the env contains " or \; sanitize/escape the
value before writing. Replace occurrences of backslash and double-quote (and
newlines) in UNSTRACT_APPS_VERSION with escaped sequences (e.g. \ -> \\ and " ->
\") or produce a safe JS string using a JSON-stringifier (jq -R . or similar)
and then insert that quoted/escaped output into the version field so
runtime-config.js remains valid; update the portion of
generate-runtime-config.sh that emits the version line to use the
escaped/JSON-encoded value instead of the raw variable.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro
Run ID: 6d3b8725-fafd-4dd7-992a-783b76071583
📒 Files selected for processing (4)
docker/dockerfiles/frontend.Dockerfilefrontend/generate-runtime-config.shfrontend/src/components/profile/Profile.jsxfrontend/src/config.js
|
|
||
| # Capture build version at the very end so it doesn't affect layer caching | ||
| ARG VERSION=dev | ||
| ENV UNSTRACT_APPS_VERSION=${VERSION} |
There was a problem hiding this comment.
@athul-rs does this get set during cloud builds as well?
There was a problem hiding this comment.
Yes — cloud frontend builds go through docker bake with *.args.VERSION=${{ inputs.tag }} (cloud-frontend-docker-build-push.yaml), same as OSS production-build.yaml, so cloud images get the rc tag baked in automatically. On-prem frontend builds use the same workflow pattern.
There was a problem hiding this comment.
@athul-rs doesn't it mean we will show rc tags in the UI?
There was a problem hiding this comment.
@ritwik-g It is relatively ok to show rc tags in UI, as long as they appear internally only.
@athul-rs That being said, since we re-tag an existing rc tag to promote it to Production, the version input for frontend display has to come from the Helm chart dynamically, instead of being baked into the image. Is this the case now? Asking since an rc tag might get displayed instead in Cloud/On-prem Production as mentioned.
jaseemjaskp
left a comment
There was a problem hiding this comment.
@athul From my point of view, the platform version is not particularly relevant to display in OSS or other environments.
For OSS, users already know which version they have deployed locally. For on-prem deployments, we maintain a version tracker and customers know exactly which version they are running. In cloud deployments, customers are always on the latest version, and we already know what version is currently deployed.
Because of that, I don’t think customers need to be aware of the platform version. I also don’t recall many enterprise applications exposing the platform version prominently in the UI.
|
@jaseemjaskp I think its useful to display the version for several reasons and we don't lose anything on attempting to do so. Its more of a convenience here
Do you see any engineering challenges or concerns in displaying this? |
…e config - ARG VERSION defaults to empty so images built without a version hide the field instead of showing 'dev' - Escape backslashes/quotes before embedding the version in the generated JS
|
@jaseemjaskp fair point — taking this back to the ticket's intent rather than pushing my own view: UN-2265 was filed by @chandrasekharan-zipstack from a suggestion that surfacing the version helps support triage (when a user reports an issue, we can ask what version the UI shows instead of cross-referencing deploy trackers). The OSS docker-compose case is the strongest one IMO: That said, this is a product call, not mine. Options as I see them:
Happy with whichever you and Chandru align on — the change is additive and cheap to drop or gate. |
|
@hari-kuriakose What should be the approach here ? Let's update the PR and ticket in jira accordingly. |
|
@athul-rs We need to show the release version in UI, dynamically pulled from the Docker compose file in OSS and Helm chart in Enterprise. Both OSS platform end users and Enterprise On-prem customer dev teams will not have a clue otherwise. A release version is a vital information when filing or debugging an issue. |
RC->stable promotion re-tags images (it does not rebuild), so a version baked
into the frontend image at build time would stay frozen at the rc tag after
promotion. Drop the frontend.Dockerfile ARG/ENV baking and instead supply
UNSTRACT_APPS_VERSION from docker-compose using ${VERSION} -- the same value
that already tags the image, so the displayed version always matches what runs.
Addresses review from @ritwik-g / @ejhari (version must come dynamically from
compose in OSS and the Helm chart in Enterprise).
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
…ion-display # Conflicts: # frontend/generate-runtime-config.sh
Frontend Lint Report (Biome)✅ All checks passed! No linting or formatting issues found. |
|



What
v0.144.0) on all deployment targets — OSS docker, cloud, on-prem.Why
UN-2265 — most apps surface their running version; users reporting issues currently have no way to tell us what version they're on, which slows down troubleshooting.
How
The version is supplied at runtime (never baked into the image) and flows env → runtime config → UI with no new endpoints:
UNSTRACT_APPS_VERSIONis provided by the deployment:docker/docker-compose.yaml):UNSTRACT_APPS_VERSION=${VERSION}on the frontend service — the same${VERSION}that already tags every image, so the shown version always matches what's running.generate-runtime-config.sh: readsUNSTRACT_APPS_VERSION(js-escaped) and injectsversionintowindow.RUNTIME_CONFIGat container start (existing mechanism).config.js: exposesconfig.version(runtime config first,VITE_VERSIONenv fallback for dev).Profile.jsx: renders the field only when a version is available, using the existing field-group styling.Why runtime env and not a build-time bake (revised after review): RC→stable promotion only re-tags images — it does not rebuild them — so a version baked into the image at build time would freeze at the
rctag and be shown in Production. Sourcing from the runtime env (compose for OSS, Helm anchor for Enterprise) keeps the displayed version aligned with the promoted release. (per @ritwik-g / @ejhari)Can this PR break any existing features. If yes, please list possible items. If no, please explain why. (PS: Admins do not merge the PR without this section filled)
UNSTRACT_APPS_VERSIONis unset (older images, local dev server, or a deployment that doesn't set it),config.versionis empty and the field simply doesn't render. No image now bakes a version, so nothing is removed that anything else depended on.Database Migrations
Env Config
UNSTRACT_APPS_VERSION(frontend container) — supplied at runtime: docker-compose passes${VERSION}in OSS; Helm injects the chart version anchor in Enterprise/On-prem (Zipstack/unstract-cloud#1621). No longer a build arg.Relevant Docs
Related Issues or PRs
UNSTRACT_APPS_VERSIONinto the frontend container from the Helm chart.Notes on Testing
sh -npasses on the runtime-config script.VERSION=v9.9.9 docker compose configrendersUNSTRACT_APPS_VERSION: v9.9.9on the frontend service; unsetVERSION→ empty → field hidden.UNSTRACT_APPS_VERSION=v1.2.3on the frontend container → profile page showsPlatform Version: v1.2.3; unset → field hidden.Screenshots
N/A
Checklist
I have read and understood the Contribution Guidelines.
🤖 Generated with Claude Code